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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Conmiittee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

Please note that the present document is a revision to TR 102 542 [i.7], and has been converted to a Technical 
Specification (TS) because the language used in the document is akin to that of a Technical Specification (TS). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 

The present document is part 1 of a multi-part deliverable covering the Guidelines for the implementation of 
DVB-IPTV Phase 1 specifications, as identified below: 

Part 1: "Core IPTV Functions"; 

Part 2: "Broadband Content Guide (BCG) and Content on Demand"; 
Part 3 : "Error Recovery" ; 

Sub-part 1: "Overview of DVB-IPTV Error Recovery"; 

Sub-part 2: "Application Layer - Forward Error Correction (AL-FEC)"; 

Sub-part 3: "Retransmission (RET)"; 
Part 4: "Remote Management and Firmware Update Services" ; 
Part 5: "Content Download System (CDS)". 
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Scope 



The present document is designed as a companion document to help implement the DVB -IPX V Phase 1 version 4: 
Transport of MPEG2-TS Based DVB Services over IP Based Networks [1], which is referred to as the DVB-IPTV 
handbook. 

The present document is the part 1 of the Guidelines and is focusing on the core IPTV functions. Other parts present 
other aspects of the DVB-IPTV technologies. 

The present document is organized in separate sections in the order of the boot-up sequence of the HNED rather than in 
the same section structure as the DVB-IPTV handbook. Each clause deals with a specific aspect of the DVB-IPTV 
technology, and offers explanations and examples not found in the DVB-IPTV handbook. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http ://docbox . etsi . or g/Ref erence . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 034 (Vl.4.1): "Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based 

DVB Services over IP Based Networks". 

[2] ETSI TS 101 154 (VI. 8.1): "Digital Video Broadcasting (DVB); Specification for the use of Video 

and Audio Coding in Broadcasting Applications based on the MPEG-2 Transport Stream" . 

[3] ETSI TS 102 824 (VI. 1.1): "Digital Video Broadcasting (DVB); Remote Management and 

Firmware Update System for DVB IP Services". 

[4] SMPTE Specification 2022-1: "Forward Error Correction for Real-time Video/ Audio Transport 

Over IP Networks". 

[5] DVB BlueBook A109: "DVB-HN (Home Network) Reference Model Phase 1 " . 

[6] Broadband Forum TR-069 Amendment 2: "CPE WAN Management Protocol", December 2007. 
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2.2 



Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

[i. 1 ] IETF RFC 3927 : "Dynamic Configuration of IPv4 Link-Local Addresses" . 

[i.2] IETF RFC 3203 : "DHCP reconfigure extension" . 

[i.3] IEEE P802.1 l-REVma/D6.0, 2006: "Unapproved Draft Standard for Information Technology- 

Telecommunications and information exchange between systems- Local and metropolitan area 
network- Specific requirements; Part 11: Wireless LAN Medium Access Control (MAC) and 
Physical Layer (PHY) specifications". 

NOTE: This document reflects the combining of the 2003 Edition of 802. 1 1 plus the 802. 1 Ig, 802. 1 Ih, 802. 1 li 
and 802. llj Amendments) (Revision of IEEE Std 802.11-1999). 



[i.4] 

[i.5] 
[i.6] 
[i.7] 

[i.8] 



IEEE 802. Id (2004) "IEEE Standard for Local and metropolitan area networks: Media Access 
Control (MAC) Bridges". 

IETF RFC 3376: "Internet Group Management Protocol, Version 3". 

IETF RFC 1 1 12: "Host extensions for IP multicasting". 

ETSI TR 102 542: "Digital Video Broadcasting (DVB); Guidelines for DVB IP Phase 1 
Handbook" . 

ETSI TS 102 542-4: "Digital Video Broadcasting (DVB); Guidelines for the implementation of 
DVB-IPTV Phase 1 specifications; Part 4: Remote Management and Firmware Update Services". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ALG Application Level Gateway 

BCG Broadband Content Guide 

BiM Binary MPEG format for XML 

CPE Customer Premises Equipment 

CRLF Carriage Return Line Feed 

DHCP Dynamic Host Configuration Protocol 

DNG Digital Network Gateway 

DSCP Differentiated Services CodePoint 

DSL Digital Subscriber Line 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

EEC Forward Error Connection 

FUS Firmware Update System 

FUSS FUS Stub file 

HN Home Network 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

IEEE Institute of Electrical and Electronics Engineers 

IETF Internet Engineering Task Force 

IGMP Internet Group Management Protocol 

IP Internet Protocol 

IPI IP Infrastructure 

LAN Local Area Network 

LCN Logical Channel Numbers 

MPEG Moving Picture Experts Group 

MPTS Multi Program Transport Stream 

NAT Network Address Translation 
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QRC 

RET 

RFC 

RMs 

RTP 

RTSP 

SD&S 

SI 

SPTS 

TS 

UDP 

XML 



Query/Response Channel 
RETransmission 
Request For Comments 
Remote Management System 
Real-time Transport Protocol 
Real Time Streaming Protocol 
Service Discovery and Selection 
Service Information 
Single Program Transport Stream 
Transport Stream 
User Datagram Protocol 
extensible Markup Language 



Background to the Scenarios 



Figure 4.1 shows the Home Reference Model for the DVB-IPTV phase 1, taken from the DVB-IPTV handbook 
(see TS 102 034 [1], clause 4.1.2). 
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Figure 4.1 : Home Reference Model (from TS 102 034 [1]) 

Figure 4.1 and the current version of the DVB-IPTV handbook [1] focuses only on the delivery of DVB-IPTV services 
over broadband delivery networks. DVB is working on enhanced home networking functionality which will for 
example allow an end user to access DVB content from several devices in the home. The Home Network Reference 
Model for this approach is provided in [5]. The protocols and functions to support this Home Network Reference Model 
will be defined in upcoming specifications and therefore not covered in the current version of the present document. 

The DVB-IPTV handbook only specifies the IPI-1 interface at the Home Network End Device (HNED). However, the 
specification of the IPI-1 interface also defines characteristics of the Home Network Segment between the HNED and 
the DNG, and in some cases what the DNG must deliver. 

The DVB-IPTV handbook intentionally does not attempt to specify where particular servers need to reside, for example 
the DHCP server. This means that no protocol is defined to operate solely on the home network segment. It also means 
that operation of one HNED is completely independent of the operation of another HNED in the same Home Network. 
Although multiple HNEDs in the same Home Network will share IP connectivity, there is no specific protocol defined 
in the DVB-IPTV handbook to allow them to exchange messages, or even know about the presence of each other. 
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The DVB -IPX V handbook does not currently define the interface IPI-2 so any routing or translation scenario that may 
be required for interworking between Home Network Segments is outside of the scope of Phase 1 of the DVB -IPX V 
handbook. Xhis means that many HNEDs can be connected to a single DNG, but multiple DNGs connected on the same 
network segment is not allowed. 



Turning on and Booting an HNED 



Xhe best way to describe how the DVB -IPX V handbook can be used is to go through what happens when you turn on an 
HNED. Xhere are a number of steps in order to have: 

Physical/MAC Layer Connection. 

IP Layer connectivity via obtaining an IP Address. 

Connection to RMS or FUS to update firmware if necessary. 

Connection to the SD&S servers. 

Discovery of BCG information (optional). 

Content Selection. 

Streaming of the video content. 

5.1 Physical/MAC Layer Connection 

Xhe physical and the link layers need to come up before anything else happens. Xhe DVB -IPX V handbook requires an 
IEEE 802 based MAC layer with priority marking according to IEEE 802. Id [i.4] within the home network segment. 
Xhese can be used by the network to help obtain the Quality of Service required for the streamed video content. 

5.2 IP Layer connectivity via obtaining an IP Address 

Once the link layer comes up, the HNED obtains the IP address from a DHCP server with the DVB mandatory DHCP 
options. Xhe DVB -IPX V handbook specifies the minimum DHCP options required to allow the DHCP server to be 
simple enough to fit into a DNG or other product on the home network segment. 

DHCP does not currently specify a way to co-ordinate the address pools of multiple DHCP servers on a network. Xhe 
DHCP client simply takes the first address offered to it but, normally, the closest available server. Xhis means that 
multiple DHCP servers cannot be used on the same network to serve the HNED. 

Xhe IP address assigned by the DHCP server will be different for each HNED on the same home network segment, but 
will be part of the same IP subnet. Xhe use of private or public IP address space and size of the subnet mask is at the 
discretion of the Network Service Provider. 

NOXE: zero-configuration mechanism: 

Whilst the DVB -IPX V handbook proposes two ways for HNEDs to get an IP address: DHCP server or via 
RFC 3927 [i.l] (lEXF zero configuration mechanism), DHCP server is the normal way. It is expected that 
the RFC 3927 [i.l] is only to be used in emergency where the DHCP server is down for some 
short-term reason. Running in zero-conf mode provides none or very little connectivity. Basically, the 
HNED does not have knowledge of a gateway device to send messages to external servers. Xherefore the 
only possible scenario is to connect to multicast streams (provided the DNG allows IGMP messages to 
flow over to the access network): first to connect to an SD&S stream, then to connect to a live XV stream. 

5.2.1 Location of the DHCP Server - Bridged and Routed modes 

Xhe following clauses detail the several IP connectivity modes that are allowed by the DVB -IPX V handbook. Xhe 
location of the DHCP server (in the HN or in the access network) has an impact on the IP connectivity of the system. 
Furthermore, a DVB -IPX V system without DHCP server can provide limited but existing services. 
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5.2.1.1 



Bridged Mode 



In the bridged mode, the DHCP server is located on the external network, typical of some DSL, or most cable or 
Ethernet to the Home deployments. The DNG then acts as a bridge or DHCP "relay" to relay the DHCP messages to the 
external DHCP server as shown in figure 5.1. Please be aware that the DVB Class options must be preserved in this 
case. 
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Figure 5.1 : Home Network in bridged mode with remote DHCP server 

In order to overcome problems with local DHCP servers and Address Translation, IPTV deployments in DSL networks 
often connect the HNED to a bridge port of the DNG which directly connects the HNED to the Access Network at the 
link layer below IP. The HNED is in this case within the IP address space of the Access Network and uses the DHCP 
server of the Access Network as shown in figure 5.2. A disadvantage is that the HNED is separate from the Home 
Network of the user which is connected via routed ports of the DNG. 
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Figure 5.2: Home Network in hybrid mode witli remote DHCP server 



5.2.1.2 



Routed Mode 



In the routed mode, the DHCP server is located in the home, it will likely be on the DNG, a scenario typical of DSL. 
The most popular means of address assignment is to have the home in a private IP address space whilst the public 
interface has an IP address given by the network operator as shown in figure 5.3. The DNG uses Network Address 
Translation to change the IP addresses of the data from public to/from private address spaces. 
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Figure 5.3: Home Network in routed mode with local DHCP server 

There is the special case where the DHCP server is not present while the Home Network is in routed mode. This 
situation is not desirable, but can happen when the DHCP server is down. In this case, zero configuration is used for the 
HNEDs to get their IP address on their own. 
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Figure 5.4: Home Network in routed mode with local DHCP server 

5.2.2 Adding a New DHCP Class Option 

The DHCP Class IDs defined in the DVB-IPTV handbook are the minimum set needed to support the types of HNEDs 
originally supported in the commercial and technical requirements. The DVB-IPTV handbook allows these attributes to 
be added to by any DVB member. 

The Class ID is meant to help the DHCP server gives the appropriate IP address for the type of HNED. It is an insecure 
method but, for example, will allow a DHCP server to give a private address to one type of HNED and a public one to 
another. Since it provides the path to the FUS Stub file (FUSS) which provides information about the RMS and FUS for 
an HNED part of the information may be manufacturer specific. 
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Following is the procedure to add a new attribute: 

1) Contact the DVB Project Office via the web site or email with the following information: 

Name of the Class ID. 

Company name. 

Contact name, email address and phone number of the legal representative who is the signatory to the 
request. 

Contact name, email address and phone number of the technical representative for the request. 

Technical and Commercial motivation for the request. 

2) The DVB Project Office will optionally contact the company. 

3) The DVB Project Office will then notify the technical and legal representative of their decision. 

4) If the decision is positive then the class ID will be published on the DVB web site and, if possible, in the next 
maintenance revision of the DVB-IPTV handbook. 



5.3 FUS and RMS Discovery 



NOTE: In this clause, the term "HNED" is used. The update capability may extend to the DNG if the logical 
RMS and/or FUS client is incorporated into the device. 

The process for acquiring the FUS Stub file (FUSS) is described in TS 102 034 [1] clause 9, shown diagrammatically 
below in figure 5.5. Several DHCP options may be used to provide the information related to locating the FUSS file for 
a HNED and the process described in TS 102 034 [1] gives a sequence in which they should be tried. 

There should be a FUS Stub file for all supported HNEDs, but the decision as to whether to download and install the 
firmware available must be made by the HNED, for example the HNED should not install older versions of the 
firmware. 

After trying these options, if no FUSS is available it must be assumed that no FUS connection is needed, and the HNED 
should continue into the normal service discovery or remote management service connection process, as appropriate to 
the HNED. 
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Figure 5.5: Acquisition of FUS Stub file and identification of firmware update 

The process may yield different types of results according to the HNED status and to different scenarios, these are 
developed below. However, it is necessary for all HNEDs to go through the FUSS acquisition process as this enables 
the status of a HNED to be changed, enabling updates such as those described below: 

• to update a new HNED populated with default firmware to either full managed or unmanaged status; 

• the remote management authority to be changed for a managed HNED where the ProductClass and 
Hard ware Version are compatible; 

• to allow a managed HNED to be made unmanaged; 

• to allow an unmanaged HNED to be made to be managed. 

5.3.1 HNED managed using Broadband Forum TR-069 methods 

Following the FUSS acquisition process for a managed HNED the RMS will be used to manage firmware updates 
possibly through the FUS and HNED configuration changes so the requirement is for the HNED to contact the RMS. 
This process will be described fully in the documentation specific to the RMS methods used, where the RMS is 
compliant with the Broadband Forum methods. This description is carried in section 3.1 of TR-069 [6]. 

The RMS can configure the entry into the FUS announcement service using the DVB extensions described in 
TS 102 824 [3]. 
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5.3.2 Unmanaged HNEDs 



In the case of an unmanaged HNED one of the options for locating the FUSS should give a result in the form of either a 
unicast or multicast URL. 
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Figure 5.6: Options for locating tlie FUSS 

The URI provided in the FUS Stub file may be either unicast or multicast with the options below: 

• The unicast URL may: 

point directly to a file image for downloading from the FUS directly 
(e.g. http://download.cisco.com/STB-Software/fredl001 .bin.). 

• The Multicast URL will be based on the "dvb-mcast" URI scheme as described in annex G.3 of 
TS 102 034 [1], and may: 

point directly to a file image for downloading from the FUS directly 
(e.g. dvb-mcast://download.cisco.com/STB-Software/fredl001.bin.); 

If SDP/SAP is used as the protocol may provide: 

■ location of the announcement message specific to the update image available; 

■ location of the entry point of the announcement message hierarchy, may be useful to point to wider 
populations (not completely populated ID info in FUSS); 

■ location of an intermediate pointer message based on wider targeting, may be useful to point to 
wider populations (not completely populated ID info in FUSS). 

If DVBSTP is used the protocol may provide: 

■ location of the XML description announcement message specific to the update image available. 

The HNED should be able to locate the firmware update using announcement description on the addresses provided. 
The detailed description of those operations is provided in TS 102 824 [3] and the associated guidelines in part 4 of this 
multi-part deliverable, TS 102 542-4 [i.8]. 
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Where the address leads to the entry point of the announcement hierarchy or an intermediate pointer further navigation 
will be needed. The capability to associate a firmware update with a specific group of HNEDs can be supported at all 
these levels with different levels of flexibility. 



5.4 Content Discovery 



Now that the HNEDs have their IP address and that they have performed the FUS process (including firmware update if 
necessary), they start looking for the SD&S servers(s) to retrieve the service lists. Figure 5.7 shows several ordered 
steps that a HNED walks through to connect to the service providers. In figure 5.7, the DHCP DISCOVER/OFFER 
messages can be mutuaHsed with the DHCP DISCOVER/OFFER from the FUS process, i.e. a single DHCP OFFER 
will be received with all information for FUS and SD&S discovery. 



DHCP 
server 



1. DHCP server sets the Domain Name option 
=>DNS SRV to the servers in the Domain Name Option 

2. DHCP server gives no Domain Name 

=>HNED connects to the lANA assigned multicast address 
224.0.23.14 



3. No Multicast data can be retrieved 

=> DNS S RV to the default server « services.dvb.org » 



4. Nothing has worked 

=> user configures manually the SD&S address 



PHCPPI5CQVER 



DHCP OFFER, 
DomainName=w.x.y.z 



ContactPNS w.x.y.z 



DHCP OFFER 
No Domain Name 



Connectto 224.0.23.14 



HNED 



DHCP OFFER NoDomainName 
Multicast Channel No Multicast Data 



Contact DNS services.dvb.org 



DHCP OFFER NoDomainName 

Multicast Channel No Multicast Data 

DNS No Answer 



Figure 5.7: SD&S server Entry Point discovery order 

5.4.1 Content Discovery in Routed Mode with Local DHCP Server 

The number of mechanisms reflects the different topologies of the service provider and in-home networks, and DNGs. 
For example, current DSL providers use DNGs with DHCP servers that sometimes do not support the DHCP Domain 
Name Option, so it is possible that the DHCP server in the DNG in the home will not support steps 1. 

However, the giaddr field will be set (it indicates the IP address of the gateway device). This means that with basic 
NAT feature on the gateway device, step 3 can be performed. The HNED can connect to the default DVB server 
(HNED 1 in figure 5.8), or better directly to a specific provider (HNED 2 - this happens when the HNED is coming 
from the content provider, so it knows the address of its server). 
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DVB 
server 



Content 
provider 




HNED1 



HNED2 



Network 
IP@ space 



Private 
IP@ space 



Figure 5.8: Content discovery with DHCP server 

5.4.2 Content Discovery in Routed Mode without DHCP Server 

Whilst an HNED without a corresponding DHCP server is an abnormal situation, HNEDs may still retrieve the service 
lists. This is by using the DVB assigned multicast address (step 2 in figure 5.7). If the DNG forwards the IGMP 
messages from the HNEDs (this is a broadcast message on the Home Network Segment, so the gateway will receive it), 
and provided that the DNG forwards incoming multicast packets from the access network into the home, then the 
DVBSTP stream can be received by the HNED. It will then build the service list based on the content of this stream. 



DVB 
server 




Multicast 

DVBSTP 

stream 



IGMPioin HNED 1 



DNG 



Network 
IP@ space 



Private 
IP@ space 




HNED 2 



Figure 5.9: Content discovery without DHCP server 

Note that this solution may work for Live Media Broadcast Content only. Live Media Broadcast Content may require 
only an IGMP message to get the AV multicast stream, without RTSP protocol. Content on Demand will not be 
possible because it requires RTSP, and the HNED does not know where to send the RTSP message (no gateway 
identified). 
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5.5 



Content Selection 



With DVB -IPX V phase 1, there are basically three ways to access content: 

• Multicast stream selection only. 

• Multicast stream selection plus RTSP. 

• Unicast stream with RTSP. 

The first two steps are for live TV content while the latter is for content on demand or Media Broadcast with Trick 
Modes services. For Live TV, the RTSP messages are not mandatory; it is perfectly possible for the HNED to just join 
the corresponding multicast group. 

5.5.1 Content Selection in Routed Mode with Local DHCP Server 

The multicast join message is sent on the HN, and the gateway forwards it to the access network. Thus the Live TV 
stream can be received by the HNED. 



Content 
provider 



Multicast 
LiveTV\ 
streaml 




HNED1 



IGMP join 



HNED 2 



Network 
IP@ space 



Private 
IP@ space 



Figure 5.10:IGMP live content selection 

If the RTSP protocol is used, the gateway needs to provide RTSP ALG (Application Level Gateway) feature: this ALG 
replaces into the RTSP message payload the values of the IP address and UDP port given by the HNED by the public 
IP address of the gateway and an available UDP port. This RTSP message will be sent before doing the multicast join. 
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Figure 5.11 : RTSP live content selection 
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Finally, in case of unicast streaming, no multicast join is necessary but the gateway still needs its RTSP ALG feature. 



Unicast 

CoD 
streaml 



Content 
provider 




HNED1 



HNED2 



Network 
IP@ space 



Private 
IP@ space 



Figure 5.12: Content on Demand selection 

5.5.2 Content Selection in Routed Mode without DHCP Server 

Again, as in clause 5.4.2, this may work provided that the DNG forward the multicast report message, and forward 
incoming multicast packets in the home. The only possibility with this configuration is to connect to a Live TV stream 
without RTSP protocol. 
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Figure 5.13: Live content selection 



5.6 Gellld Configuration 



Some IPTV services are subject to regionalization, i.e. they are available only in specific geographical areas. The 
regionalization information is present in the description of the IPTV service or package (see clause 6.4.2 of the present 
document) in the form of a pair Country/Cellld. The Cellld is the string parameter within the "Cell" XML tag. 

While the regionalization of an IPTV service is dependent on the IPTV service provider (definition of the cell 
boundaries and identification names), the location of the HNED is dependent on the network provider (physical 
connection to the IP network). Thus, the DVB -IPTV mechanism to retrieve the cellld is based on such location 
information that has to be matched against IPTV service provider regionalization information. 
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In order to know which IPTV service or package is available, the HNED has to know its own pair Country/Cellld. The 
HNED retrieves first its location parameters. This is done thanks to the DHCP option 99 (Civic Address). This DHCP 
option provides the country code and a set of Civic Address parameters. The country code will be matched as-is against 
the country code XML element of the IPTV service and package. The cellld is retrieved in two possible ways: 

• Pull mode: the HNED sends a HTTP POST request to the IPTV service provider, which returns back the 
assigned cellld. The HTTP POST includes all Civic Address elements as received within the DHCP option 99, 
following the Cell XML element structure. 

• Push mode: the HNED connects to the Regionalization Discovery Record for the IPTV service provider, 
parses it to retrieves its cellld. As the Regionalization Discovery Record does not contain necessarily all Civic 
Address parameters, the match is done only on parameters that are present in the record structure. 

In this way, the HNED does not care about the meaning of the Civic Address parameter, this is dealt with between the 
Network Provider and the IPTV service provider. The IPTV Service Provider can ask the Network Provider to include 
private parameter (Civic Address Type 132). 



6 SD&S Service Discovery 

6.1 Push and Pull modes 

Once one of the ways of selecting the Service Discovery entry points has been chosen, the HNED knows the entry 
points and can access the SD&S server either in multicast or unicast way. For each entry point, the HNED collects the 
Service Provider Discovery information. 

The Service Provider Discovery Information may be (according to the IP address class of the Service Discovery entry 
point): 

• Multicast (Push model): The HNED sends an IGMP Report request to a multicast address in order to 
subscribe to this multicast group. The content of the "Provider" XML file is carried by the DVBSTP protocol 
with a payload id value set to 0x01 (see table 1: Payload ID values of TS 102 034 [1]). 

• Retrieved on request (Pull model). In this case, the HNED sends a HTTP request: 

'GET /dvb/sdns/sp_discovery?id=ALL HTTP/1.1' CRLF 
'Host: ' <host> CRLF 

or 

'GET /dvb/sdns/sp_discovery?id=<Domai2ii\rame> HTTP/1.1' CRLF 
'Host: ' <host> CRLF 

Both models are supported. 

The HNED gets thus the Service Providers' list and their Push or Pull offers. The HNED selects the Push [Multicast 
IP address (IGMP), content of XML file carried by DVBSTP] or Pull (in this case, it is done through a HTTP request) 
offers of its Service Provider. 

For information, the Payload ID values of the different SD&S services are shown in table 1 of TS 102 034 [1]. 

Service discovery information is represented as XML records (examples are given hereafter). In order to be managed 
efficiently by the HNED, SD&S records are fragmented into a number of smaller units, called Segments. Segments may 
be transported uncompressed or compressed using BiM. 

BiM compression reduces the size of the SD&S XML records significantly, therefore its use is recommended in 
constrained environments. When the network provider uses BiM compression, it shall also make available 
uncompressed Segments (in Push, Pull or both modes). 



ETSI 



20 ETSI TS 1 02 542-1 V1 .3.1 (201 0-01 ) 

6.2 Strategies for SD&S Service Discovery 

6.2.1 Choosing between push and pull modes 

Multicast and HTTP sources for SD&S information are extracted first from the Entry Point Discovery process and then 
from Service Provider descriptions. For each of these steps, the HNED may find either only one transport model 
provided or both. When both are provided, they convey exactly the same information (XML records) so there is a 
choice to use one method or the other. Using the HTTP mode has the drawback of increasing the server load 
proportionally to the number of HNED on the network, which can be millions. Multicast mode has the drawback of a 
potential delay of 30 seconds in order to scan a complete carrousel cycle. A general recommendation for "fair 
behaviour" of the HNED would be then to prefer multicast mode when no specific reason asks for an immediate 
acquisition of some information (which is however never guaranteed) and reserve the use of HTTP for infrequent 
situations where the application needs to provide up-to-date information quickly to the end user. 

6.2.2 Different scenarios regarding transport of multiple segments 

6.2.2.1 Finding the segment lists 

When using an entry point address in pull mode, the HTTP request always sends back the complete service discovery 
record without segmentation. This can be the complete set for all service providers (request with "id=ALL") or a 
specific service provider record ("id=< domain name of the service provider>"). 

When receiving SD&S information from multicast address(es), the DVBSTP header has a payload ID field and a 
segment ID field on each packet. These fields allow to capture the list of segments for each payload type by listening to 
a complete carrousel cycle time. 

Additionally service provider records may list the segments that are made available through each announced source 
(either push or pull). This list is mandatory for pull sources since there is no other way (see note) in this case to get the 
list. It may be provided for push mode since this allows the HNED to know if it has acquired everything without 
necessarily waiting for the maximum cycle time. 

NOTE: Actually there is a way: send a request to get each possible segment number and see which succeed or 
fail. But this is not practically feasible with 65 536 possible segment IDs. 

6.2.2.2 Filtering service providers in DVBSTP 

The DVB-IPTV handbook allows the case where several Service Providers use independent equipments to serve their 
own SD&S data. It is then possible that several service providers use the same multicast group to send DVBSTP 
packets containing the descriptions of their offer (Service Provider Discovery records). Then because the service 
providers are not centrally coordinated, they might well choose segment IDs that are the same. 

The DVBSTP has a ServiceProviderlD field, mandatory in this kind of configuration, that is used to signal the 
service provider identity (in the form of an IP address unique to the service provider). This allows the HNED to sort the 
received information and build a correct list of segments assigned by each service provider. See TS 102 034 [1], 
clause 5.4.1.3.3. 

6.3 Acquisition of Live Channels Services 

The acquisition of Live Channels services is performed through the retrieval of the content of the "Package" and 
"Broadcast" files. 

NOTE: Live Channels can also be retrieved thanks to the BCG; this is presented in the BCG clause of the present 
document. 

If there is a Package service, the HNED can collect (via Push or Pull mode) the "service names" of the channels 
composing its bouquet. 

Then, the HNED can access (via Push or Pull mode) the XML file that contains the BroadcastDiscovery structure. 
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For the Broadcast Discovery Information Record, there are two modes: 

• "TS Full SI" (SD&S + DVB-SI): 

It provides only the necessary SD&S information to find available live media broadcast services which have 
embedded SI. Information on individual services is afterwards acquired from the transport stream itself 
through classical use of service information as defined in DVB -SI. As even the service name is not provided in 
SD&S, the HNED needs to connect to all services and parse all SI to build the service list. 

• "TS Optional SI" (only SD&S): 

It provides all the necessary SD&S information to create a list of available services with sufficient information 
for the user to make a choice and gives the necessary information on how to access the service. 

In the following part, we consider the "TS Optional SI" mode. 

6.4 Complete SD&S example 

This clause presents a workable example of SD&S discovery, and shows all different DVB-IPTV technologies that can 
be used (packages, FEC, regionalization, media transport). 

6.4.1 Service Provider Discovery Record 

As an example, the Service Provider discovery record below contains 2 service providers: "Providerl" and "Provider2". 
Each provider proposes 2 services: a Package service (Pay load ID value=5) and a Broadcast service (Payload ID 
value=2). 





Providerl 


Provider2 


Services 


Package 
(Payload ID value=5) 


Package 
(Payload ID value=5) 


Broadcast 
(Payload IDvalue=2) 


Broadcast 
(Payload IDvalue=2) 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi = "http: //www. w3 . org/2 l/XMLSchema- instance " > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName= "providerl . com" LogoURI="0" Version="0"> 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f fering> 

<Push Address="224.1.1.5" Port="1234" Source=" 192 . 100 . 100 . 70 " > 
<PayloadId Id="5"> 

<Segment ID="1" Version="2 "/> 
</PayloadId> 
</Push> 
</0f f ering> 
<0f f ering> 

<Push Address="224.1.1.2" Port="1234" Source=" 192 . 100 . 100 . 70 " > 
<PayloadId Id="2"> 

<Segment ID="3" Version="2 "/> 
</PayloadId> 
</Push> 
</0f fering> 
</ServiceProvider> 

<ServiceProvider DomainName="provider2 . com" LogoURI="0" Version="0"> 
<Name Language="ENG" >Provider2</Name> 

<Description Language="ENG" >Provider2 ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224 .1.1.6" Port="1234" Source="192 . 100 . 100 . 75" > 
<PayloadId Id="5"> 

<Segment ID="0" Version=" 0"/> 
</PayloadId> 
</Push> 
</0f f ering> 
<0f fering> 

<Push Address="224.1.1.3" Port="1234" Source=" 192 . 100 . 100 . 75 " > 
<PayloadId Id="2"> 

<Segment ID="2" Version="3 "/> 
</PayloadId> 
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</Push> 
</0f fering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 



6.4.2 Package and Broadcast Discovery with Regionalization 

As an example, the "Package" file below corresponds to the "Providerl". For this service provider, 2 bouquets are 
proposed: "Providerl Bouquetl" and "Providerl Bouquet2". The bouquet "Providerl Bouquetl" contains the channels 
"Channel 2", "Channel 3" and "Channel 5". The bouquet "Providerl Bouquet2" contains the channels "Channel 7", 
"Channel 8" and "Channel 9". The provider uses UDP streaming. 

Furthermore, the service provider assigns Logical Channel Numbers (LCN) to services described in the SD&S records, 
as presented in the following table, and also provides availability information. 





Providerl Bouquetl 


Providerl Bouquet2 


Channels 


Channel2 


LCN = 1 


Channel 7 


LCN = 2 


Channels 


LCN = 3 


Channel 8 


LCN = 4 


Channels 


LCN = 6 


Channel 9 


LCN = 5 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http: //www. w3 . org/2 l/XMLSchema- instance " > 

<PackageDiscovery DomainName= "providerl . com" Version="0"> 
<Package Id="l"> 

<PackageName Language="ENG" >Providerl Bouquetl</PackageName> 
<Service> 

<TextualID ServiceName= " Channel2 " / > 
<LogicalChannelNumber= " 1 " /> 
</Service> 
<Service> 

<TextualID ServiceName= " Channel3 " / > 
<LogicalChannelNumber="3 "/> 
</Service> 
<Service> 

<TextualID ServiceName= " Channels " / > 
<LogicalChannelNumber= " 6 " /> 
</Service> 
<PackageAvai lability > 

< Count ryCode Ava i 1 ab i 1 i t y = " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Ireland</Cell> 
</PackageAvai lability > 
</Package> 
<Package Id="2"> 

<PackageName Language="ENG" >Providerl Bouquet2</PackageName> 
<Service> 

<TextualID ServiceName="Channel7"/> 
<LogicalChannelNumber= " 2 " / > 
</Service> 
<Service> 

<TextualID ServiceName= "Channels "/> 
<LogicalChannelNumber= " 4 " / > 
</Service> 
<Service> 

<TextualID ServiceName="Channel9"/> 
<LogicalChannelNumber= " 5 " / > 
</Service> 
<PackageAvai lability > 

<CountryCode Availability="f alse" >UK</CountryCode> 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
</PackageAvai lability > 
</Package> 
</PackageDiscovery> 
</ServiceDiscovery> 
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As an example, the "Broadcast" file below corresponds to the "Providerl". We retrieve in the broadcast discovery 
record the ServiceName from the package discovery record. The package record provides the logical channel number, 
while the broadcast record provides the complete information on the service. 





Providerl 


Channels 


Channel 2 


Channel 3 


Channel 5 


Channel 7 


Channel 8 


Channel 9 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi = "http: //www. w3 . org/2 l/XMLSchema- instance " > 

<BroadcastDiscovery DomainName= "providerl . com" Version="0"> 
<ServiceList> 

<ServicesDescriptionLocation> 

<DescriptionLocation>bcgl</DescriptionLocation> 

<DescriptionLocation pref erred="true" >bcg2</DescriptionLocation> 
</ServicesDescriptionLocation> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 12 " Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2 " /> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 
<MaxBitrate>4 0</MaxBitrate> 
<ServiceAvai lability > 

< Count ryCode Ava i 1 ab i 1 i t y = " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Ireland</Cell> 

< /ServiceAvai lability > 
<ServiceAvai lability > 

<CountryCode Aval lability="t rue " >FR</ Count ryCode > 
< /ServiceAvai lability > 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<lPMulticastAddress Address="224 . Ill . 1 . 13 " Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName= "Channels "/> 
<DVBTriplet OrigNetld="0" Serviceld="5003 " TSld="203"/> 
<MaxBitrate>4 0</MaxBitrate> 
< ServiceAvai lability > 

< Count ryCode Ava i 1 ab i 1 i ty = " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>lreland</Cell> 

< /ServiceAvai lability > 
< ServiceAvai lability > 

<CountryCode Availability=" true" >FR</CountryCode> 
< /ServiceAvai lability > 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<lPMulticastAddress Address="224 . Ill . 1 . 15" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<Textualldentif ier DomainName= "providerl . com" ServiceName="Channel5"/> 
<DVBTriplet OrigNetld="0" Serviceld="5005" TSld="205"/> 
<MaxBitrate>4 0</MaxBitrate> 
< ServiceAvai lability > 

< Count ryCode Ava i 1 ab i 1 i t y = " t rue " >UK< / Count ryCode > 
<Cell>Scotland</Cell> 
<Cell>Ireland</Cell> 

< /ServiceAvai lability > 
< ServiceAvai lability > 

<CountryCode Availability="true" >FR</CountryCode> 
< /ServiceAvai lability > 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 27" Port="8208" Source="192 . 100 . 100 . 50" 
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Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName="Channel7"/> 
<DVBTriplet OrigNetId="0" Serviceld="5007" TSId="207"/> 
<MaxBitrate>4 0</MaxBitrate> 
<ServiceAvai lability > 

<CountryCode Availability="f alse" >UK</CountryCode> 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
< /ServiceAvai lability > 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 28" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<Textualldentif ier DomainName="providerl . com" ServiceName="Channel8 " /> 
<DVBTriplet OrigNetld="0" Serviceld="5008" TSld="208"/> 
<MaxBitrate>4 0</MaxBitrate> 
< ServiceAvai lability > 

<CountryCode Availability="f alse" >UK</ Count ryCode> 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
< /ServiceAvai lability > 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 29" Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<Textual Identifier DomainName=" provider 1 . com" ServiceName="Channel9"/> 
<DVBTriplet OrigNetId="0" Serviceld="5009" TSId="209"/> 
<MaxBitrate>4 0</MaxBitrate> 
< ServiceAvai lability > 

<CountryCode Availability="f alse" >UK</ Count ryCode> 
<Cell>Scotland</Cell> 
<Cell>Wales</Cell> 
< /ServiceAvai lability > 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 

NOTE: The Service Availability in the broadcast record matches the Package Availability in the package record, 
but can also contain more parameters, as shown with the first package and the first 3 services defined 
there. 

6.4.3 Package and Broadcast Discovery with Error Recovery 

As an example, the "Package" file below corresponds to the "Provider2". For this service provider, only one bouquet is 
proposed: "Provider2 Bouquet". The bouquet "Provider2 Bouquet" contains the channels "Channel 15", "Channel 16", 
"Channel 17" and "Channel 18". The provider uses RTP streaming and provides FEC protection for channels 15 (only 
base layer) and channel 16 (base and enhancement layers), and RET protection for channels 17 and 18. 





Provider2 Bouquet 


Channels 


Channel 15 


Channel 16 


Channel 17 


Channel 18 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http: //www. w3 . org/2 l/XMLSchema- instance " > 

<PackageDiscovery DomainName="provider2 . com" Version="0"> 
<Package Id="3"> 

<PackageName Language="ENG" >Provider2 Bouquet</PackageName> 
<Service> 

<TextualID ServiceName=" Channel 15"/> 
</Service> 
<Service> 

<TextuallD ServiceName=" Channel 16"/> 
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</Service> 
<Service> 

<TextualID ServiceName=" Channel 17"/> 
</Service> 
<Service> 

<TextualID ServiceName=" Channel 18"/> 
</Service> 
</Package> 
</PackageDiscovery> 
</ServiceDiscovery> 



As an example, the "Broadcast" file below corresponds to the "Provider2". 





Provider2 


Channels 


Channel 15 


Channel 16 


Channel 17 


Channel 18 



/^ 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http: //www. w3 . org/2 l/XMLSchema- instance " > 

<BroadcastDiscovery DomainName="provider2 . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 15" Port="8208" Source="192 . 100 . 100 . 20" 
Streaming="rtp" FECMaxBlockSizePackets="8" FECMaxBlockSizeTime="100" > 
<FECBaseLayer Address="224 . 222 . 2 . 15" Port="8210" Source="192 . 100 . 100 . 20" 
PayloadTypeNumber="96" MaxBitrate="3 00" /> 
</lPMulticastAddress> 
</ServiceLocation> 

<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 15"/> 
<DVBTriplet OrigNetId="0" Serviceld="6001" TSId="5"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 16" Port="8208" Source=" 192 . 100 . 100 . 20 " 
Streaming="rtp" FECMaxBlockSizePackets="8" FECMaxBlockSizeTime="10 0" 
FECOTI = "MDB j MTA1MDE= " > 

<FECBaseLayer Address="224 . 222 . 2 . 16" Port="8210" Source="192 . 100 . 100 . 20" 
<FECEnhancementLayer Address="224 . 222 . 3 . 16" Port="4304" 

Source="192 . 100 . 100 .20" MaxBitrate="200 " PayloadTypeNumber="102 " 
TransportProtocol="RTP-AVP" /> 
</lPMulticastAddress> 
</ServiceLocation> 

<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 16"/> 
<DVBTriplet OrigNetId="0" Serviceld="6002 " TSId="6"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 17" Port="8208" Source="192 . 100 . 100 . 20" 
St reaming= " rtp " > 
<RTPRetransmission> 

<RTCPReporting DestinationAddress="192 . 100 . 100 . 9" DestinationPort="65" /> 
</RTPRetransmission> 
</lPMulticastAddress> 
</ServiceLocation> 

<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 17"/> 
<DVBTriplet OrigNetId="0" Serviceld="6003 " TSId="7"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 18" Port="8208" Source="192 . 100 . 100 . 20" 
St reaming= " rtp " > 
<RTPRetransmission> 

<RTCPReporting DestinationAddress="192 . 100 . 100 . 8" DestinationPort="54" /> 
</RTPRetransmission> 
</lPMulticastAddress> 
</ServiceLocation> 
<TextualIdentif ier DomainName="provider2 . com" ServiceName=" Channel 18"/> 
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<DVBTriplet OrigNetId=" " Serviceld="6004 " TSId="8"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 

NOTE: FEC Base Layer is compliant to SMPTE 2022-1 [4], so it is strongly recommended that the Address 

field is identical to the Address field of the content itself, and the Port field is +2 from the Port field 
of the content. Note that any other values will break compliance with SMPTE 2022-1 [4]. 

6.5 More Complex Examples for SD&S 

This clause intends to present SD&S examples dealing with all possibilities offered by the DVB-IPTV handbook. 

6.5.1 Service Provider Discovery 

6.5.1 .1 Service Provider Discovery with Redundant Push/Pull Locations 

The aim of the following record is to advertise a broadcast discovery record several times, pointing to different 
servers/multicast addresses. This allows the HNED to connect to different servers in case some of them are 
momentarily not responding. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName="providerl . com" LogoURI="0" Version="0"> 
<Name Language= " ENG " >Provider 1 < /Name > 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
// one same package offering announced several times 
<0f fering> 

<Pull Location= "packages .providerl . com/dvb/sdns/" > 
<Payloadld ld="5"> 

<Segment lD="12cf" Version="2e"/> 
<Segment lD="3 0d2" Version="ac"/> 
<Segment 1D="12" Version="2 "/> 
</Payloadld> 
</Pull> 

<Pull Location= "packages .otherlocat ion. providerl . com/dvb/sdns/" > 
<PayloadId Id="5"> 

<Segment ID="12cf" Version="2e"/> 
<Segment ID="3 0d2"/> 
<Segment ID="12"/> 
</PayloadId> 
</Pull> 
<Push Address="224 .1.1.5" Port="1234" Source="192 . 100 . 100 . 70" > 

<PayloadId Id="5"/> 
</Push> 

<Push Address="224.1.3.5" Port="5678" Source=" 192 . 100 . 100 . 70 " > 
</Push> 

<Push Address="224 .1.7.5" Port="1234" Source="192 . 100 . 100 . 70" > 
<PayloadId Id="5"/> 

<Segment ID="12cf" Version="2e"/> 
<Segment ID="3 0d2"/> 
<Segment ID="12"/> 
</PayloadId> 
</Push> 
</0f f ering> 
// one broadcast offering announced 
<0f fering> 

<Push Address="224.1.1.2" Port="1234" Source=" 192 . 100 . 100 . 70 " > 
<PayloadId Id="2"> 

<Segment ID="12cf" Version="2e"/> 
</PayloadId> 
</Push> 
</0f fering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 
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In this example, the first offer is a package discovery record which is announced through 4 different possibilities, 
2 pull and 3 push. Note that: 

• for the pull mode, the location of the server is different, but segments are the same since the same content is 
available; 

• for the push mode, it is not mandated to announce segments; it is not even mandated to announce the payload 
id. In that case, the HNED will check when receiving the header of the DVBSTP packets. 

The second offer is a broadcast one; it has the same segment and version as the first offer, which is acceptable because 
we talk here about a different offer. 

NOTE: The Payload @ ID attribute is expressed in the XML data structure in hexadecimal coded with 1 or 2 
characters, while it is coded with exactly 2 characters in the URL of the HTTP request. 
The Segment® ID attribute is expressed in the XML data structure in hexadecimal coded with 1 to 4 
characters, while it is coded with exactly 4 characters in the URL of the HTTP request. 
The Segment ©Version attribute is expressed in the XML data structure in hexadecimal coded with 1 or 2 
characters, while it is coded with exactly 2 hexadecimal characters in the URL of the HTTP request. 
For example, for the first pull location: 

<Pull Location= "packages .providerl . com/dvb/sdns/" > 
<PayloadId Id="5"> 

<Segment ID="12cf" Version="2e'7> 
<Segment ID="30d2" Version="ac"/> 
<Segment ID="12" Version="2 "/> 
</PayloadId> 
</Pull> 
the HTTP requests to retrieve the segments are: 

GET /dvb/sdns/service_discovery?id=providerl . com&Payload=05&Segment=12cf &Version=2e 
GET /dvb/sdns/service_discovery?id=providerl . com&Payload=05&Segment=30d2&Version=ac 
GET /dvb/sdns/service_discovery?id=providerl . com&Payload=05&Segment=0012&Version=02 



6.5.1 .2 Service Provider Discovery with Complementary Push/Pull Locations 

In the previous example we talked about redundancy for the announcement of the SD&S data. It consumes server 
resource and bandwidth resource to do that, while a service provider may want to optimize the resources to send the 
SD&S data. 

Let us base the following example on a broadcast offering by a service provider (other payload ids can of course be 
used). We assume a service provider has 200 TV channels. If no splitting at all was performed, the offering can be 
included in a unique segment sent on one multicast group. Assuming an average size of each single service XML record 
of 1 k-byte, we have 200 k-bytes to send in a maximum delay of 30 seconds. This produces a bitrate of 53 kbits/s in the 
SD&S multicast. 

At the opposite, we can build 200 segments, each one containing the description for only one service, and assign a 
different multicast group to the sending of each segment such as illustrated below. There is also the possibility to split 
the HTTP server load, here 2 servers are defined, to hold odd and even segment numbers (but any split is possible, with 
any number of servers). 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName= "providerl . com" LogoURI="0" Version="0"> 
<Name Language="ENG" >Providerl</Name> 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
// one broadcast offering announced in several pieces 
<0f fering> 

<Push Address="224. 1.7.0" Port="1234" Source=" 192 . 100 . 100 . 70 " > 

<PayloadId Id="2 "/xSegment ID="0"/></PayloadId> 
</Push> 
<Push Address="224. 1.7.1" Port="1234" Source=" 192 . 100 . 100 . 70 " > 

<PayloadId Id= "2 "/xSegment ID="l"/></PayloadId> 
</Push> 
<Push Address="224 .1.7.2" Port="1234" Source="192 . 100 . 100 . 70" > 

<PayloadId Id="2 "/xSegment ID="2 "/></PayloadId> 
</Push> 
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[ ] 


<Push Address="224.1.7.198" Port="1234" Source=" 192 . 100 . 100 . 70 " > 


<PayloadId Id="2 "/xSegment ID="c6"/></PayloadId> 


</Push> 




<Push Address="224.1.7.199" Port="1234" Source=" 192 . 100 . 100 . 70 " > 


<PayloadId Id="2 "/xSegment ID="c7"/></PayloadId> 


</Push> 




<Pull Location=" 


services0to99 .providerl . com/dvb/sdns/" > 


<PayloadId Id="2"> 


< Segment 


ID="0'7> 


< Segment 


ID="2"/> 


< Segment 
[ 


ID="4"/> 
] 


< Segment 


ID="c4"/> 


< Segment 


ID="c6"/> 


</PayloadId> 




</Pull> 




<Pull Location=" 


servicesl00tol99 .providerl . com/dvb/sdns/" > 


<PayloadId Id="2"> 


< Segment 


ID="l"/> 


< Segment 


ID="3"/> 


< Segment 
[ 


ID="5"/> 
] 


< Segment 


ID="c5"/> 


< Segment 


ID="c7"/> 


</PayloadId> 




</Pull> 




</0f fering> 




</ServiceProvider> 




</ServiceProviderDiscovery> 




</ServiceDiscovery> 





Sending each multicast stream with a cycle time of 30 seconds makes a bitrate of only 266 bits/s for each. So the HNED 
which wants to check only a few channel descriptions generates a bandwidth of only a few times these 266 bits/s. 

If the HNED wants to monitor everything simultaneously, it will join all the multicast groups and receive a total bitrate 
of 52 kbits/s - the same as if only one stream was used. This can be used for example at boot time to acquire the 
complete service plan. Since each stream cycles in 30 seconds, the HNED still receives the complete information in 
30 seconds. 

Then since SD&S updates are not frequent, the HNED might decide to listen to only one multicast group at a time. This 
uses a permanent bandwidth of only 266 bits/s. Each segment is received in (maximum) 30 seconds. So at most after 
30 seconds, the HNED leaves the current group and joins the next one. The total time to scan all the information is now 
(maximum) 1 hour and 40 minutes. 

Between the 2 extreme options - all in one segment and one service per segment with one stream per segment - the 
service provider has much flexibility to find a good compromise between the use of bandwidth, the time it takes to 
check updates and the number of multicast addresses used (which may be limited). 

6.5.1 .3 Simplest Service Provider Discovery Offer 

Since the Payload element is not required for push location, the following XML table is the simplest possible one for 
service provider discovery. Of course the only way for the HNED to know what is offered is to join the multicast 
groups and check the payload id within the DVBSTP headers. Note that the Source field of the Push element is 
optional, it was not set here. 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName= "providerl . com" LogoURI="0" Version="0"> 
<Name Language= " ENG " > Provider 1 < /Name > 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224.1.1.5" Port="1234" /> 
</0f fering> 
<0f f ering> 

<Push Address="224.1.1.2" Port="1234" /> 
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</0f f ering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 



6.5.2 Broadcast Offering with Multiple Multicast/RTSP Locations 

It is also possible to provide several locations that allow access to the content. The following example presents a 
complex example with several push and pull locations. There are 2 RTSP servers able to provide session management 
for this live content, one multicast stream using UDP streaming without FEC, and one multicast stream using RTP with 
FEC. 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<RTSPURL>rtsp: //live .providerl . com/Channel2 .mpg</RTSPURL> 

<lPMulticastAddress Address="224 . Ill . 1 . 12 " Port="8208" Source="192 . 100 . 100 . 50" 

Streaming="udp" /> 
<IPMulticastAddress Address="224 . Ill . 1 . 22 " Port="4302" 

Streaming= " rtp" FECMaxBlockSizePackets= " 8 " FECMaxBlockSizeTime= " 10 " > 
<FECBaseLayer Address="224 .111.1.22 Port="4304" Source="192 . 100 . 100 . 50" /> 
</lPMulticastAddress> 

<RTSPURL>rtsp: //live .proxy .providerl . com/Channel2 .mpg</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2 " 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



7^ 



NOTE: The order of service locations is not important, therefore there is no preference or default location 
implied. 

6.5.3 Single Big Push Discovery 

Since DVBSTP has all information in the header of the packet to discriminate payload ids and segments, it is possible 
for a service provider to provide all the SD&S data on one single multicast address. The following XML tables are an 
example of such a system. 

The entry point provides the multicast address 224.1.1.1 to discover the Service Provider Discovery record. This record 
is as follows: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn: dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName= "providerl . com" LogoURI= 
<Name Language="ENG" >Providerl</Name> 
<Description Language= 
<0f f ering> 

<Push Address="224 
</0f fering> 
<0f f ering> 

<Push Address="224 
</0f fering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 



Version= 



'ENG">Providerl ADSL TV Of f er</Description> 
1.1.1" Port="1234" /> 



1.1.1" Port="1234" /> 
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Let us say that the first offering is a package record, and the second one is a broadcast record. 

The multicast group 224.1.1.1 is carrying three different payload ids data: the service provider discovery record (1), the 
broadcast record (2) and the package record (5). Each payload id can have several segments. 

The HNED will perform the parsing of payload ids and segment thanks to the DVBSTP header. 

6.5.4 Multiple Coding Formats 

The SD&S data structure can provide audio and video formats used by the service. When a service provider is able to 
present the same service using several different formats (size, coding, etc.), it has to advertise several services in the 
service list. 

The following example shows the case of one service being available in SD and HD formats. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 12 " Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName=" Channel -1 SD"/> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 
<MaxBitrate>4 0</MaxBitrate> 
<SI ServiceType="01" PrimarySISource="XML" > 

<Name Language="ENG" >Channel 1 - SD</Name> 
<Name Language="FRA" >Canal 1 - SD</Name> 

<Description Language="ENG" >This is the channel 1 in SD</Description> 
<Description Language="FRA" >Ceci est le canal 1 en SD</Description> 
</SI> 
<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : VisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</SingleService> 
<SingleService> 

<ServiceLocation> 

<lPMulticastAddress Address="224 . Ill . 1 . 13 " Port="8208" Source="192 . 100 . 100 . 50" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName="providerl . com" ServiceName=" Channel -1 HD"/> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="203"/> 
<MaxBitrate>10 0</MaxBitrate> 
<SI ServiceType="19" PrimarySISource="XML" > 

<Name Language="ENG" >Channel 1 - HD</Name> 
<Name Language="FRA" >Canal 1 - HD</Name> 

<Description Language="ENG" >This is the channel 1 in HD</Description> 
<Description Language="FRA" >Ceci est le canal 1 en HD</Description> 
</SI> 
<AudioAttributes> 

<Coding href =" urn: dvb : metadata : cs :AudioCodecCS : 2 007 : 1 .2 .2"> 

<Name>MPEG-4 High Efficency Advanced Audio Profile @ Level 2</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

<Coding href = "urn: dvb : metadata : cs :VideoCodecCS : 2 007 : 1 .4 . 12"> 

<Name>H264 High Profile @ Level 4.0</Name> 
</Coding> 
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</VideoAttributes> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



6.6 Regionalization and Logical Channel Numbers (LCN) 

A HNED has used the SD&S mechanism to discover the available service providers and services in the IPTV network. 
The service provider assigns Logical Channel Numbers (LCN) to services described in the SD&S records. The LCN 
defines the service provider's preferred ordering of the available services in the HNED channel list. The LCN is a 
number associated with every service, allowing the presentation of the service and its selection. 

In this example all regional Channel2 services are listed contiguously, but they all use the same channel number since 
they are not supposed to exist simultaneously. 



LCN 


Channel 


Regional Availability 
(CelM) 


Regional Availability 
(Cell 2) 


1 


Channel2 regioni 


true 


false 


1 


Channel2 region2 


false 


true 


1 


Channel2 regions 


false 


false 


1 


Channel2 region4 


false 


false 


2 


Channels 


true 


true 


3 


Channels 


true 


true 



In Cell 1: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb :metadataipi : : iptv: sdns :2006:2008-l" 

xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 

<PackageDiscovery DomainName="providerl . com" Version="0"> 
<Package Id="l"> 

<PackageName Language="ENG" >Providerl Bouquet l</PackageName> 
<Service> 

<TextualID ServiceName="Channel2 regioni "/> 
<LogicalChannelNumber=l/> 
</Service> 
<Service> 

<Textual ID ServiceName= " Channels " / > 
<LogicalChannelNumber=2 / > 
</Service> 
<Service> 

<Textual ID ServiceName= " Channels " / > 
<LogicalChannelNumber=3 / > 
</Service> 
</Package> 
</PackageDiscovery> 
</ServiceDiscovery> 



In Cell 2: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb :metadataipi : : iptv: sdns :2006:2008-l" 

xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 

<PackageDiscovery DomainName="providerl . com" Version="0"> 
<Package Id="l"> 

<PackageName Language="ENG" >Providerl Bouquet l</PackageName> 
<Service> 

<TextualID ServiceName="Channel2 region2"/> 
<LogicalChannelNumber=l/> 
</Service> 
<Service> 

<TextualID ServiceName=" Channels "/> 
<LogicalChannelNumber=2 / > 
</Service> 
<Service> 

<TextualID ServiceName= " Channels " /> 
<LogicalChannelNumber=3/> 
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</Service> 
</Package> 
</PackageDiscovery> 
</ServiceDiscovery> 



6.7 RMS-FUS Announcement Discovery 

A Service Provider may use an SD&S record carried over DVBSTP transport and identified by PayloadID = 0x08 to 
deliver information about the firmware update server (FUS) and the remote management service. 

For any RMS-FUS SD&S record the segmentid must have a value other than "0". In order to compact the payload for 
these messages during carriage GZIP may be used. 

There may be a single RMS-FUS SD&S record leading to an appropriate entry point in the FUS multicast 
announcement structure or multiple RMS-FUS SD&S records carrying information for different CPEs. Further 
navigation may be necessary within the FUS multicast announcement structure. 

The detailed description of how the information carried using this method of delivery can be used to used is contained 
in TS 102 824 [3] and in Part 4 of this multi-part deliverable [i.8]. 

The description of the FUS may include: 

• its identity; 

• the multicast and unicast addresses of the announcement services; 

• the query/response channel (QRC) supported by that FUS. 

The RMS may be described in terms of its identity and the URI of the management channel (interface 9 of the 
RMS-FUS logical architecture shown in TS 102 824 [3]. 

Some examples based on the schema described in TS 102 034 [1] are given below. 

In this example an FUS named "Echostar_FUS_3" is identified offering connection information using multicast to the 
announcement service, carried over DVBSTP, and the location of the QRC for that FUS. This record is intended to 
support an unmanaged CPE so no RMS is described. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http: //www. w3 . org/2 l/XMLSchema- instance " > 
<RMSFUSDiscovery Version="0"> 

<FUSProvider LogoURI=" http : //lO .1.1. 34/LogoFUS . jpg " > 
<FUSName Language="ENG" >Echostar_FUS_3</FUSName> 
<FUSID>1234</FUSID> 

<Description Language="ENG" >FUS for EchoStar IPTV</Description> 
< FUSAnnouncement > 

<FUSAnnouncementDescription> 

Update to add improved menu features 
</FUSAnnouncementDescription> 
<MulticastAnnouncementAddress Address="224 . 122 .2.23" Port="4321" 

Protocol="2 DVBSTP" /> 
<QRCLocation> http : //example . f us . dvb . org : 8080/QRC </QRCLocation> 

<FUSUnicastAnnouncement> http : //example . f us . dvb . org/UCFUS </FUSUnicastAnnouncement> 
< /FUSAnnouncement > 
</FUSProvider> 
</RMSFUSDiscovery> 
</ServiceDiscovery> 

In this example the multicast address provided must lead into the announcement system at a level only for CPEs 
covered by the description at the entry point identified, e.g. in the example the announcements should only describe 
firmware updates for CPEs maintained by the FUS. Also further navigation through the announcement system may be 
needed to identify the actual firmware update for the CPE. 

The provision of the QRC location allows the CPE to provide sufficient information over the unicast channel to the FUS 
for the FUS to provide the location information for the available firmware updates, but this can only be done based on 
comparisons of the information provided by the CPE with the metadata provided by the manufacturer. A more complete 
description of the use of the QRC is given in Part 4 of this present document. 
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In the next example the record describes an RMS("Echo_RMS_Eui"), no FUS information is required because that is 
managed through the RMS, with the connection being made over the management channel. It is assumed that the CPE 
will contact the RMS which will provide the information to acquire the firmware update file to the CPE. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" > 
<RMSFUSDiscovery Version="5"> 

<RMSProvider RMSLocation=" http : //example . rms .dvb . org: 7547 " > 
<RMSName Language="ENG" >Echo_RMS_EUl</RMSName> 
<RMS1D>12 34</RMS1D> 

<Description Language="ENG" >RMS serving EchoStar lPTV</Description> 
</RMSProvider> 
</RMSFUSDiscovery> 
</ServiceDiscovery> 

Both FUS and RMS information can be provided if desired, as in the example below. Note that the FUS and RMS are 
identified as different entities implying that they are physically separated as shown in the RMS-FUS architecture but 
they could be co-located in the same device. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn: dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 
<RMSFUSDiscovery Version="0"> 

<FUSProvider LogoURl=" http : //lO .1.1. 34/LogoFUS . jpg " > 
<FUSName Language="ENG" >Echostar_FUS_3</FUSName> 
<FUSID>1234</FUSID> 

<Description Language="ENG" >FUS for EchoStar IPTV</Description> 
< FUSAnnouncement > 

<FUSAnnouncementDescription> 

Update to add improved menu features 
</FUSAnnouncementDescription> 
<MulticastAnnouncementAddress Address="224 . 122 .2.23" Port="4321" 

Protocol="2 DVBSTP"/> 
<QRCLocation> http: //example. fus.dvb.org: 8080/QRC </QRCLocation> 

<FUSUnicastAnnouncement> http : //example . f us . dvb . org/UCFUS </FUSUnicastAnnouncement> 
< / FUSAnnouncement > 
</FUSProvider> 

<RMSProvider RMSLocation=" http : //example . rms .dvb.org: 7547 "> 
<RMSName Language="ENG" >Echo_RMS_EUl</RMSName> 
<RMS1D>12 34</RMS1D> 

<Description Language="ENG" >RMS serving EchoStar lPTV</Description> 
</RMSProvider> 
</RMSFUSDiscovery> 
</ServiceDiscovery> 



6.8 Versioning and Update Signalling 

TS 102 034 [1], clause 5.4.3 contains information on signalling changes in SD&S. The subsequent clause provides 
additional guidance and examples. 

6.8.1 Location of Version Information 

There are several locations where version numbers are provided in the SD&S mechanism. The list is numbered to 
reference the locations in the text afterwards. 

1) a Version attribute is present at the root level of the ServiceDiscovery XML element ([1], 
clause C.1.5); 

2) a Version attribute is present in the Of f eringBase XML element ([1], clause C. 1.4. 24). This 
Of f eringBase element is inherited by all Discovery records (Broadcast record, BCG record . . .) 

3) a Version attribute is present at the ServiceProvider level in the Service Provider Discovery record 
(Service Provider Type XML element, [1], clause C. 1.3. 39) and at the BCG level in the BCG Discovery 
record (BCGOf f ering XML element, [1], clause 1.4.1); 
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4) a Version attribute is present in the segment element used in the PayloadList ([1], clause C. 1.3. 29) of a 
Service Provider discovery record and BCG discovery record. 

5) A Segment_Version field is present in the header of the DVBSTP packet ([1], clause 5.4.1.1). 

6.8.2 Example using the BCG Discovery Record 

To show all Versions fields, we will use here an example with a BCG Discovery record. This example is quite complex 
on purpose. The BCG Discovery record is presented since it is the only one that is able to carry all Versions fields. All 
other records miss one Version field: the Service Provider Discovery record carries (3) but not (2), all other Offering 
records carry (2) but not (3). 

In this example, we present at first the Service Provider Discovery record that points to the BCG Discovery record. For 
the latter, DVBSTP transport is assumed, and while all version fields are set, some are optional and may be missing in 
real deployments. They are provided here as an example with all possible version fields present, since the DVB-IPTV 
handbook [1] does not forbid putting those Version fields. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 
xmlns :xsi= http : //www. w3 . org/2001/XMLSchema-instance Version=| 
<ServiceProviderDiscovery> 

<ServiceProvider DomainName="providerl . com" LogoURI="0" Versic 
<Name Language= " ENG " > Provider 1 < /Name > 

<Description Language="ENG" >Providerl ADSL TV Of f er</Description> 
<0f f ering> 

<Push Address="224.22.23.24" Port="1234" Source="67 . 89 . 01 . 23 " > 
<PayloadId Id="6"> /^'^ 

<Segment ID="13" Version=f 5d"^ 4 
</PayloadId> ^— ^ 

</Push> 
</0f fering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 

DVBSTP header 

I Ver |Resrv| Enc I C| Total_Segment_Size | 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - l^ H ^ + 

I Payload ID= 6 | Segment ID = 13 | SegVersion=r 5d J 5 

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + ->*4-^ 

I Section_Number | Last Section Number | Compr | | HDR_LEN | 

XML Document (DVBSTP payload) 

<?xml version="l . 0" encoding="UTF-8" ?> 

<Service^a?i5«overy xmlns= "urn: dvb : ipisdns : 2 006" xmlns :xsi= http : //www. w3 . org/2001/XMLSchema-instance 

Version=f 5d"^ 1 ^— ^ 

<BCGlj!h»frovery DomainName="p]^e''^iS^erl . com" Version=f42 " :^ 2 
<BCG Id="bcgl" Version=r 2a"^ 3 ^-^ 

<Name Language="eng'^>^«^viderl BCG1</Name> 
<TransportMode> 

<HTTP Location="bcgl .providerl . com/dvb/sdns/" > 
<PayloadId Id="al"> ^->^ 

<Segment ID="7b" Versionf^"4" A 4 
<Segment ID="4d5" Versioi^^Hr7"/> 
<Segment ID="1" Version="2 "/> 
</PayloadId> 
<PayloadId Id="a2"> 

<Segment ID="0" Version="4 "/> 
</PayloadId> 
</HTTP> 
</TransportMode> 

<TargetProvider>sport .providerl . com</TargetProvider> 
</BCG> 
<BCG Id="bcg2" Version="8"> 

<Name Language="eng" >Providerl BCG2</Name> 
<TransportMode> 

<DVBSTP Port="5512" Address="224 . 235 . 32 . 4 " > 
<PayloadId Id="al"> 
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<Segment ID="7" Version="6"/> 
</DVBSTP> 
</TransportMode> 

<TargetProvider>news .providerl . com</TargetProvider> 
</BCG> 
</BCGDiscovery> ^— ^ 

<BCGDiscovery DomainName="p]^©^iS^erl . com" Version=r'3 " >! 2 
<BCG Id="bcg3" Version=r 3 " >) 3 ^— ^ 

<Name Language="eng'^>ftroviderl BCG3</Name> 
<TransportMode> 

<HTTP Location="bcg3 .providerl . com/dvb/sdns/" > 
<PayloadId Id="al"> ^->^ 

<Segment ID="11" Versionf"l"A 4 
</PayloadId> ^ — ^ 

</HTTP> 
</TransportMode> 

<TargetProvider>movies .provider2 . com< /Target Provider > 
</BCG> 
</BCGDiscovery> 
</ServiceDiscovery> 



6.8.3 Carriage of version numbers 



Where the version numbers are carried depends on the transport protocol used to deUver the SD&S segments. The 
numbers in parenthesis refer to the numbered list above. 

• The version of a Service Provider (3) shall be always present. The version of a BCG (3) is optional in the 
DVB-IPTV handbook, but this Guidelines document strongly recommends that it is always present, in the 
same way the Service Provider one is. 

• If a segment is delivered using HTTP (pull mode): 

The version field at the root of the XML document (1) shall be present. 

When the record is an Offering record (based on the OfferingBase XML element), the version field of 
the OfferingBase (2) shall be present. 

• If a segment is delivered using DVBSTP (push mode), i.e. IP multicast: 

The version field is present in the DVBSTP header (5) of the segment. 

It is recommended that the version attributes (1) and (2) are not used. If it is present (1) shall be equal to 

(5). 

• The version number (4) of a Service Discovery information segment can optionally be signalled in the segment 
list that is contained in the ServiceProvider record, whether it is for HTTP or for DVBSTP. In the same way 
the version of a BCG container can be signalled via the BCG Discovery record. 

• As a BCG container does not contain its version number the version field it is strongly recommended that (4) 
is present for HTTP signalling of BCG containers. 

6.8.4 Update Detection 

The update of a SD&S record is signalled using the version numbers. The update mechanism can be summarized by the 
following logic: 

• Any change in an SD&S XML element increases the version of the corresponding record: 

this change will increase the Version attribute of the ServiceProvider or BCG level (3); 

this change will increase the Version attribute of the XML record (2) when this field is present 

(e.g. ServiceDicsovery .BroadcastDiscovery@Version for BroadcastDiscovery records). 

• Consequently, this change will also increase the Version attribute of the root level of the record (1), when 
this field is present (i.e. the ServiceDiscovery@Version) ; 
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• Consequently, this change will also increase the Segment_Version field of the DVBSTP packet header (5) 
when the record is transported in push mode. It will also increase the Version field of the PayloadList 
XML element (4), when this field is present. 

• Consequently, if this change is within an offering record (not the ServiceProviderDi scovery record), 
it means that the offering has changed, and this has to be reflected in the ServiceProviderDi scovery 
record where the offering records belongs to by increasing its version. Thus the 

ServiceProvider@Version (3) will be increased. This is done whether (4) is present or not, since the 
offering has changed; 

• Consequently, the Version attribute of the XML segment carrying the ServiceProviderDi scovery 

( 1 ) record will also be increased when this field is present (when delivered in pull mode). When sent in push 
mode, the Segment_Version field of the DVBSTP packet header (5) will be increased. 

As a summary, the following figures present the change chain of versioning. Changes are the squares in the records; 
arrows mean that the impact is to increase the version number pointed out by the arrow, in a sequential way. Different 
colours are used for different examples. The first figure is for the push mode via DVBSTP. 

Figure 6.1 presents an initial state of the records, with all version fields present: 



DVBSTP header 



Ver Resrv Enc C 


Total_Segment_Size 


Payload ID= 1 Segment 


ID= |SegVersion= 9 | 


Section_Number 


Last Section Number Compr HDR_LEN 



Ver Resrv Enc C 


Total_Segment_Size 


Payload ID= 2 Segment 


ID= 12cf |SegVersion= 2 | 






Section_Number 


Last Section Number Compr HDR_LEN 



Service Pro vider Disco very record 



<ServiceDiscovery Version="9"> 
<ServiceProviderDi scovery > 

<ServiceProvider Version="7"> 
<Name 

<Description 
<0f fering> 
<Pull 

<PayloadId Id="2"> 

<Segment ID="12cf" Version="2 "/> 
<Segment ID="30d2" Version="3 "/> 
</PayloadId> 
</Pull> 
</0f fering> 
</ Service Provider > 
</ ServiceProviderDi scovery > 
< ServiceProviderDi scovery > 

<ServiceProvider Version="2"> 
<Name 

<Description 
<0f fering> 

<Push 
</0f fering> 
</ Service Provider > 
</ServiceProviderDiscovery> 
</ServiceDi scovery > 



<ServiceDiscovery> 

<BroadcastDiscovery Version="^ 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<RTSPURL 
</ServiceLocation> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDi scovery > 



BroadcastOffering 

Record 

First segment 



Figure 6.1 : Initial state of the records with all version fields 
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When some changes occurred, those records become: 



DVBSTP header 



Ver Resrv Enc C 


+ 


+ 


"^ 


+ 


-+ + 


Total Segment 


Size 


+ - + - 


+ + 


--+-+-+-+- 


+-+-+-+ 


- + 


+ 


+ 


+ 


- + - + - 


+-+-+-+-+-+-+-+ 


- + 


-+-+-+-+ 


+ - + - 


+ - + -- 


Payload 


ID= 1 1 


Segment 


ID= 






SegVersion= 


10 


--+-+-+-+- 


+-+-+-+ 


- + 


+ 


+ 


+ 


- + - + - 


+-+-+-+-+-+-+-+ 


- + 


-+-+-+-+ 


.'^ 


K-+-- 


Section 


Number 


- + 


+ 


+ 


1 


Last 
- + - + - 


Section Number 


- + 


Cornp*^ 


) |HDR 
+ - + - 


_LEN 



I Ver I Resrv I Enc I C I Total_Segment_Size | 

I Payload ID= 2 | Segment ID= 12cf | SegVersionj*. 3 | 

I Section_Number | Last Section Number ICfM-rt^rl 1 HDR_LEN | 



Service Pro vider Disco very. 



<ServiceDiscovery Version="a 

<ServiceProviderDiscover;; 

<ServiceProvider Vers 

trliTnma 
<Descriptio 
rfJffaifingn 
<Pull 

<PayloadId 

<Segment \lD="12cf " Version=" 
<Segment \[D="3 0d2" Version="3 "/> 
</PayloadId> 
</Pull> 
</0f fering> 
</ServiceProvider> 
</ServiceProviderDiscovery> 
<ServiceProviderDiscovery> 

oinT|)TiQoPinoT|)Tido ^ Versio^ 
<Name 




change [ 



<0f f ering> 

<Push 
</0f f ering> 



Tu^ida JT Versioj^" 



</ServiceProvider> 
</ServiceProviderDiscovery> 
</ServiceDiscovery> 




<ServiceDiscovery> 

<BroadcastDiscovery Version^ 
<ServiceList> 
<SingleSerj& 

luTiaoLoaati ! 



</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 





BroadcastOffering 

Record 

First segment 



Figure 6.2: State of the records with all version fields after changes 

It is important to note that the DVB -IPX V handbook [1] does not provide any strict rule on the version increase 
mechanism itself. In the previous example, several changes occurred and though the version is only increased by one. 
This is a service provider choice whether the versions are increased at each change, or if the versions are increased by a 
group of changes, in which case the frequency of increase actions is also a service provider implementation choice. 

Figures 6.3 and 6.4 show the same records, but with only mandatory version fields. When delivered with DVBSTP: 



DVBSTP tieaders 



I Ver I Resrv I Enc I C I Total_Segment_Size | 

+ -H h-+-+-+-+-+-+-+- + - + - + - + - + - + -H h-H h-H h-H 1 h- + - + - + - + - + - + -+- + 

I Payload ID= 1 | Segment ID= |SegVersion= 10 | 

+ -H h-+-+-+-+-+-+-+- + - + - + - + - + - + -H h-H h-H h-H 1 h- + - + - + - + "^^+/(+ " + 

I Section_Number | Last Section Number | Compr | Q^J^Dr/leN 



Ver I Resrv | Enc | C | Total_Segment_Size 

h-+-+-+-+-+-+- + - + - + - + - + - + - + -+-+-+-H h-H 1 h-H V-' 

Payload ID= 2 | Segment ID= 12ce |SegVersion= 3 

h-+-+-+-+-+-+- + - + - + - + - + - + - + -+-+-+-H h-H 1 V- 

Section_Number | Last Section Number | Cojo^i^ro | HDJTleN | 




Figure 6.3: Records with only mandatory version fields with DVBSTP transport 
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And when HTTP is used, there is no DVBSTP header anymore: 



ServiceProviderDiscovery record 



BroadcastOffering Record 



<ServiceDiscovery Version="a"^ 

<ServiceProviderDiscoverilb^v?""'" 
<ServiceProvider Vers:\on= 
<Name 

<Description 
<0f f ering> 
<Pull 

<PayloadId l\i="2" 

<Segment \lD="12cf " Version="3" 
<Segment \[D="3 0d2" Version="3 "/> 
</PayloadId> 
</Pull> 
</Offering> i ii 

</ServiceProvider> 
</ ServiceProviderDiscovery > 
<ServiceProviderDiscovery> 

Version= 
<Name 

^jDGaaL"ipfeio A 
<0f fering> 

<Push 
</0f f ering> 
</ServiceProvider> 
</ ServiceProviderDiscovery > 
</ServiceDiscovery> 




<ServiceDiscovery> 

<BroadcastDiscovery Ver sioa 
<ServiceList^ 

ervice> 
<Sp 

<RTSPURL 
</^idi 'JiuidLUUclLitn> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



Figure 6.4: Records with only mandatory version fields with HTTP transport 



7 Connection to the Content 

At this step, the HNED has collected the XML files that contains the content description (SD&S or BCG structures). 
The HNED can then connect to the content. This will involve different mechanisms whether the content is live 
broadcast or on-demand. 



7.1 



Connection to Live Content 



Live content is typically described using SD&S metadata, but it can also be exposed using BCG metadata. 

7.1 .1 Connection possibilities 

A Live TV service may be accessed by an individual HNED in the following ways: 

• Using Internet Group Management Protocol (IGMP): 

In this case, the HNED has collected a Multicast IP address for this Live TV service. To display this Live TV 
channel, the HNED sends an IGMP Report request to this Multicast IP address in order to subscribe to this 
multicast group. Multicast Content Services use IGMP version 3 with Source Specific Multicast. This allows 
significant scalability and implementers should note that the previous version of IGMP is not allowed (see 
clause 7.3 for details). 

• Using Real Time Streaming Protocol (RTSP): 

In this case, the HNED has collected a RTSP URL for this Live TV service. This RTSP URL gives all the 
information necessary to issue the appropriate RTSP method. Parameters required for the IGMP message will 
be acquired via the SETUP method from RTSP. 

7.1 .2 Live Content exposed with SD&S 

Within SD&S, the Multicast IP address is exposed thanks to the "SingleService.ServiceLocation.IPMulticastAddress" 
XML element, with an optional "Source" attribute in case of source filtering. 

In case of RTSP, the URL is exposed thanks to the "SingleService.ServiceLocation.RTSPURL" XML element. 

For an example of a "Package" file and a "Broadcast" file, see clause 6.4. 
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7.3 Multicast Connection Management 

The DVB-IPTV handbook mandates IGMPv3 (RFC 3376 [i.5]) for the IPI-1 interface. What does it mean? 

7.3.1 IGMPvl 

IGMPvl (RFC 1112 [i.6]) defines the following message: 

12 3 

01234567890123456789012345678901 

I Version I Type | Unused | Checksum | 

I Group Address | 



The 2 messages types (Type) are: 

• Host Membership Query, value=l 

• Host Membership Report, value=2 
As version is 1 , this gives for the first octet: 

• Host Membership Query, value=Oxl 1 

• Host Membership Report, value=0xl2 
The Unused field is set to zeroes. 

7.3.2 IGMPv2 

IGMPv2 defines the following message: 

12 3 
01234567890123456789012345678901 

1 Type I Max Resp Time | Checksum | 
I Group Address | 

The message Types values are: 

• 0x1 1: Membership Query (General Query or Specific Query). 

• 0x16: v2 Membership Report. The IP packet is sent to eh specific multicast address. 

• 0x17: Leave Group. The IP packet is sent to the all routers group (224.0.0.2). 

The Max Resp Time field reflects the maximum time before sending a response for the host; this allows managing 
timers in a more efficient way. 
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7.3.3 IGMPv3 



IGMPv3 defines the following Membership Query message: 



12 3 
01234567890123456789012345678901 

I Type = 0x11 I Max Resp Code | Checksum | 

I Group Address | 

I Resv |S| QRV | QQIC | Number of Sources (N) | 

I Source Address [1] | 

+ - - + 

I Source Address [2] | 

+ - . - + 



+ - - + 

I Source Address [N] | 



The Max Resp Code field is quite equivalent to the v2 Max Resp Time, with possibilities for more complex 
values. 

7.3.4 Impact is on the HNED 

In IGMPv3 (RFC 3376 [i.5]), clause 7.2.1 says: "In order to be compatible with older version routers, IGMPv3 hosts 
MUST operate in version 1 and version 2 compatibility modes". So having a DVB-IPTV compliant HNED means that 
it follows the IGMPv3 spec, meaning that it must conform to this statement. 

The detection of which version of IGMP runs on the router is done by looking at the Query message received: 

• IGMPvl Query: length = 8 octets AND Max Resp Code field is zero. 

• IGMPv2 Query: length = 8 octets AND Max Resp Code field is non-zero. 

• IGMPv3 Query: length >= 12 octets. 

Thus it is possible that the HNED be connected to network with previous versions of IGMP, though such a 
configuration would not take advantage of IGMPv3 enhancement. 

7.4 RTSP Connection Management 

7.4.1 RTSP with SD&S 

This clause will present call flows for RTSP session management as announced from the SD&S metadata. The first 
example will be the simplest one, with only one RTSP address. The second example will involve EEC and RET flows 
that also need their own RTSP sessions. 
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7.4.1 .1 RTSP Session with one media flow 

The following service is announced via SD&S: 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

</SingleService> 
<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 1 . 12 " Port="8208" Source="192 . 100 . 100 . 50" 

Streaming="udp" /> 
<RTSPURL>rtsp : //live . providerl . com/Channel2 . mpg</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2 "/> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 
<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 

NOTE 1 : the operator can announce IP multicast concurrently with RTSP URL. This can be useful for example in 
the case of park upgrade where some old HNEDs cannot use RTSP while the new HNEDs use preferably 
RTSP. 

The following shows an example of message exchange between the HNED and the RTSP server. At first, the HNED 
may send a RTSP DESCRIBE to retrieve information about the service. 



DESCRIBE rtsp: //live. providerl .com/Channel2 .mpg RTSP/1. 



CSeq: 1 

Accept: text/xml 



The DESCRIBE response from the server includes an XML structure that is in fact the Broadcast Offering for this 
service. 

RTSP/l.O 200 OK 

Cseq: 1 

Content -length: 1306 

Content-Type: text/xml 

Content -Encoding: UTF-8 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http: //www. w3 . org/2 l/XMLSchema- instance " > 

<BroadcastDiscovery DomainName= "providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . Ill . 5 . 44" Port="5502" Source="192 . 100 . 100 . 70" 
Streaming="udp" /> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2 " /> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 
<MaxBitrate>4 0</MaxBitrate> 
<SI ServiceType="01" PrimarySISource="XML" > 

<Name Language="ENG" >Channel 2 - SD</Name> 
<Name Language="FRA" >Canal 2 - SD</Name> 

<Description Language="ENG" >This is the channel 2 in SD</Description> 
<Description Language="FRA" >Ceci est le canal 2 en SD</Description> 
</SI> 
<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 
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<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : VisualCodingFormatCS :2001:2.2.2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



NOTE 2: In this example, the multicast address retrieved from the RTSP DESCRIBE is not the same as the one 
originally announced within the Broadcast Offering. Of course it can also be the same. 

The HNED perform a SETUP for this service. In this example, only one SETUP is necessary since only one RTSP URL 
is exposed and only one media flow is sent on the network (the MPEG2-TS stream). 



SETUP rtsp: //live.providerl .com/Channel2 .mpg RTSP/1.0 

CSeq: 2 

Transport : RTP/AVP;multicast ;destination=224 . Ill .5 . 44 ; source=192 . 100 . 100 . 70 ;port=5502-5503 



RTSP/1.0 200 OK 

Cseq: 2 

Session: 12345678 ; timeout=60 

Transport : RTP/AVP ; multicast ;destination=2 24 . Ill .5 . 44 ; source=192 .10 0.100. 70 ;port=5502-5503 



NOTE 3: In case there are multiple multicast addresses available for the service, the HNED can put several 

Transport headers in the SETUP request, in which case the server will answer with only one Transport 
header in the SETUP response, indicating the multicast address to be used by the HNED. 

Then the HNED sends the PLAY message to the server. In case of multicast, this does not perform the connection to the 
service, the IGMP Join message will do so. This informs the RTSP server that this HNED is connecting to this service. 
This can also inform intermediate devices of this connection. 



PLAY rtsp: //live.providerl .com/Channel2 .mpg RTSP/1.0 

CSeq: 3 

Session: 12345678 



RTSP/1.0 


2 00 OK 


















Cseq: 3 




















Session: 


12345678 


















RTP-Info 


url= rtsp 


//live 


. providerl 


com/Channel2 


mpg, 


seq= 


=11223344 


;rtptime= 


=10203040 



7.4.1 .2 RTSP Sessions with multiple media flows 

The following service is announced via SD&S. In this example, we use a minimal SD&S announce, all the information 
will be carried within the response to the DESCRIBE message. 



<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns= "urn : dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2001/XMLSchema-instance" > 

<BroadcastDiscovery DomainName= "providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

</SingleService> 
<SingleService> 

<ServiceLocation> 
<RTSPURL> 

rtsp: //live .providerl . com/Channel2 
</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2 "/> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 



ETSI 



43 



ETSI TS 102 542-1 VI .3.1 (2010-01) 



<MaxBitrate>4 0</MaxBitrate> 
</SingleService> 
<SingleService> 

</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 



The following shows an example of message exchange between the HNED and the RTSP server. At first, the HNED 
may send a RTSP DESCRIBE to retrieve information about the service. 



DESCRIBE rtsp: //live.providerl .com/Channel2 RTSP/1.0 

CSeq: 1 

Accept: text/xml 



The DESCRIBE response from the server includes an XML structure that is in fact the Broadcast Offering for this 
service. 

RTSP/1.0 200 OK 

Cseq: 1 

Content -length: 1847 

Content-Type: text/xml 

Content -Encoding: UTF-8 

<?xml version="l . 0" encoding="UTF-8" ?> 

<ServiceDiscovery xmlns="urn:dvb : metadata : iptv: sdns : 2008-1" 

xmlns :xsi="http : //www. w3 . org/2 l/XMLSchema- instance" > 

<BroadcastDiscovery DomainName="providerl . com" Version="0"> 
<ServiceList> 

<SingleService> 

<ServiceLocation> 

<IPMulticastAddress Address="224 . 222 . 2 . 16" Port="8208" Source="192 . 100 . 100 . 20" 
Streaming="rtp" FECMaxBlockSizePackets="8" FECMaxBlockSizeTime="10 0" 
FECOTI = "MDB j MTA1MDE= " > 

<FECBaseLayer Address="224 . 222 . 2 . 16" Port="8210" 
Source="192 . 100 . 100 .20" MaxBitrate="200 " 

RTSPControlURL="rtsp: //live.providerl . com/Channel2?FecBase" /> 
<FECEnhancementLayer Address="224 . 222 . 3 . 16" Port="4304" 
Source="192 . 100 . 100 .20" MaxBitrate="200 " 

RTSPCont rolURL= " rt sp : / / 1 ive . provider 1 . com/Channel2 ? FecEnhancement " / > 
</lPMulticastAddress> 
<RTSPURL RTSPControlURL="rtsp: //live.providerl . com/Channel2?Media" > 

rtsp: //live .providerl . com/Channel2 
</RTSPURL> 
</ServiceLocation> 

<TextualIdentif ier DomainName= "providerl . com" ServiceName="Channel2 "/> 
<DVBTriplet OrigNetId="0" Serviceld="5002 " TSId="202"/> 
<MaxBitrate>4 0</MaxBitrate> 
<SI ServiceType="01 PrimarySISource="XML" > 

<Name Language="ENG" >Channel 2 - SD</Name> 
<Name Language="FRA" >Canal 2 - SD</Name> 

<Description Language="ENG" >This is the channel 2 in SD</Description> 
<Description Language="FRA" >Ceci est le canal 2 en SD</Description> 
</SI> 
<AudioAttributes> 

< Coding href =" urn: mpeg:mpeg7 : cs : AudioCodingFormatCS :2001:3.2"> 

<Name>MPEG-l Audio Layer II</Name> 
</Coding> 

<NumOf Channel s>2</NumOf Channel s> 
</AudioAttributes> 
<VideoAttributes> 

<Coding href =" urn: mpeg:mpeg7 : cs : VisualCodingFormatCS : 2 001 :2 .2 .2"> 

<Name>MPEG-2 Video Main Profile @ Main Level</Name> 
</Coding> 
</VideoAttributes> 
</SingleService> 
</ServiceList> 
</BroadcastDiscovery> 
</ServiceDiscovery> 
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The HNED perform then several SETUP for this service: one SETUP is needed for each flow, i.e. one for the media 
flow (using the RTSPControlURL of the media flow), and one for each EEC layer (using the RTSPControlURL of the 
EEC layers). If the HNED does not want to connect to a flow, it will not issue the corresponding SETUP command. In 
this example, the HNED will only connect to the media flow and to the EEC Base layer. 



SETUP rtsp://live.providerl .com/Channel2?Media RTSP/1.0 

CSeq: 2 

Transport : RTP/AVP;multicast ;destination=224 .222 .2 . 16 ; source=192 .10 0.100 . 20 ;port=8208-8209 



RTSP/1.0 200 OK 

Cseq: 2 

Session: 12345678 ; timeout=60 

Transport : RTP/AVP;multicast ;destination=224 . 222 .2.16; source=192 . 100 . 100 . 20 ;port=8208-8209 



SETUP rtsp 


//live .providerl . 


com/Channel2?FecBase 


RTSP/1 



















CSeq: 3 






























Session: 12345678 




























Transport : 


RTP/AVP 


multicast 


;destination= 


= 224 


222 


2.16; source= 


= 192 


100 


100 


20 


;port= 


= 8210- 


-8211 



RTSP/1.0 200 OK 

Cseq: 3 

Session: 12345678 ; timeout=60 

Transport : RTP/AVP;multicast ;destination=224 .222 .2 . 16 ; source=192 .10 0.100 . 20 ;port= 821 0-8211 



Then the HNED sends the PLAY message to the server. Only one PLAY is needed for both flows. In case of multicast, 
this does not perform the connection to the service, the IGMP Join message(s) will do so. This informs the RTSP server 
that this HNED is connecting to this service with the specific SETUP as previously performed. This can also inform 
intermediate devices of this connection. 



PLAY rtsp : //live. providerl .com/Channel2 RTSP/1.0 

CSeq: 4 

Session: 12345678 



RTSP/1.0 


2 00 OK 


Cseq: 4 




Session: 


12345678 


RTP-Info 


url=rtsp: //live. providerl . com/Channel2?Media; seq=11223344 ; rtptime=10203040 , 


url=rtsp 


//live. providerl . com/Channel2?FecBase; seq=55667788 ; rtptime=5 06 0708 



7.5 Transport of the stream 



The video content is streamed using an MPEG-2 transport stream, as defined in TS 101 154 [2], which is then 
encapsulated in RTP/UDP or directly in UDP. Usually a Single Program Transport Stream (SPTS) is used as only the 
bandwidth for the selected content is needed. However Multi Program Transport Streams (MPTS) are not out ruled. 

The information if RTP/UDP or UDP encapsulation is used is provided by the SD&S Broadcast Discovery record 
attribute IPMulticastAddress@ Streaming or the BCG locator for multicast services and by the RTSP transport header 
for unicast services: 

• A IPMulticastAddress@ Streaming value of "rtp" indicates RTP/UDP encapsulation. 

• A IPMulticastAddress@ Streaming value of "udp" indicates direct UDP encapsulation. 

In case the IPMulticastAddress@ Streaming attribute is not defined in the SD&S record RTP/UDP encapsulation is 
assumed. 

A RTSP transport header of "RTP/AVP/UDP" indicates RTP/UDP encapsulation. A RTSP transport header of either 
"MP2T/H2221/UDP" or "RAW/RAW/UDP" indicates direct UDP encapsulation. 
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8 Typical applications available within the scope of the 

DVB-IPTV phase 1 handbook 

DVB -IPX V Phase 1 is a significant step in standardizing entertainment video over IP home network; however, it does 
not cover all possibilities or areas for standardization. This clause attempts to outline its boundaries with the belief that 
future versions of the standard will extend the scope. 

The boundaries can be broken down into a number of areas: 

AudioA^ideo transport and codecs. 

Topology. 

Networking Addressing and Discovery. 

Network Level Security. 

Operation over different physical networks and Quality of Service. 

DNG/HNED only networks. 

8.1 Video transmission and codecs 

The current version of the DVB-IPTV handbook only addresses the use of an MPEG-2 transport stream for the delivery 
of content. It does not address separation of the transport stream into elementary streams or any other carrier other than 
the MPEG2 transport stream. 

The transport over IP is via RTP and UDP or via UDP directly (without RTP). For the later the network has to ensure 
that no packet reordering occurs. 

In case of RTP encapsulation a single PCR per MPTS should be used. 

AL-FEC is only supported with RTP/UDP encapsulation. It is not supported for direct UDP encapsulation of the 
transport stream. 

Supported media formats are given in TS 101 154 [2]. 

8.2 Topology 

The current version of the DVB-IPTV handbook is limited to the following simple in-home network topologies: 

• DNG/HNED Only Networks. 

• Single Segment Home Networks with single address space and single DHCP server. 

These are quite restrictive topologies but simple enough to satisfy the majority of current uses cases. This means that a 
network consisting of two DNGs in the home must be on independent and unconnected network segments. 

8.3 Networking Addressing and Discovery 

The standard uses DHCP to obtain network addressing and several other pieces of information but the option table is 
deliberately short to make client implementation simple in the HNED. However the implementation does use the new 
server message outlined in RFC 3203 [i.2] "FORCERENEW" which is not usually implemented in most DHCP servers. 

The DHCP message also requires a unique identifier so the reuse of MAC addresses by whatever method is not 
allowed. 

The DHCP server non-availability has been designed to be an unusual occurrence so whilst the use of RFC 3927 [i.l] is 
recommended in emergency, temporary situations; a DHCP server will be required for a DVB-IPTV home network to 
function normally. 
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8.4 Network Level Security 

Network level security, for example, denial of service attacks are not covered in the DVB -IPX V handbook. 

8.5 Operation over different piiysical networl<s and Quality of 
Service 

The design of DVB -IPX V Phase 1 is physical layer independent and relies on the IP network to provide the required 
quality of service. The DVB -IPX V specifications are easily met on most wired networks but less so by in-home wireless 
networks, particularly 802.11 networks. 

The DVB -IPX V handbook defines only the user priority classes for the different traffic types and the related DSCP and 
IEEE 802. Id [i.4]priority values. No QoS enforcement mechanisms are defined. 

8.6 DNG/HNED Only Networks 

The requirement for a combination of DNG/HNED e.g. a DSL modem combined with a set-top box, means that the 
DVB -IPX V handbook phase 1 treats this box as effectively a DNG and this is outside of the scope of the specification. 

However, if this box has any Ethernet or other interface capable of providing a network for example 
IEEE 802.11a/g [i.3] wireless LAN then it falls under the specification of DVB-IPTV. 
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